Traditional information services are now in a state of rapid evolution created by the need to address their customers growing dependency on accessible, relevant information. One of the most significant products of this evolution is the distribution of information resources throughout the system, that is, the creation of highly distributed information services.
One noted example of this evolution is the World Wide Web (WWW). In this example resources, usually in the form of digital documents, are distributed through the Internet and are accessed by users through one of many possible browser interfaces. The access model is that of "client/server" with the browser being the client and the Web server being the server. In this model the clients may access a file (bookmarks) or query a well-known search engine (another information service) as the first step in locating a particular document or resource. This access or query results in an identifier, called a Uniform Resource Locator (URL), that uniquely identifies the document or resource that resides in the system, and can be used to access the desired resource.
As in the above example of the Web, most distributed information services resources are identified by names which are resolved into some unique representation that identifies the location, and possibly other characteristics, of a single specific service. Resolution in these distributed systems is usually static and one-to-one (i.e. the name resolves to one and only one unique representation). The static nature of the resolution process does not permit the service to adapt itself to any variations in client or infrastructure behavior. A simple example of this inflexibility can be seen when situations on the Web arise such that the local or global client load increases dramatically (this can be due to new versions of software becoming available or a partitioning of the network which causes some parts of the service to be inaccessible) and the service cannot scale itself to accommodate the performance and accessibility requirements of its clients.
These flexibility constraints herald the need for a mechanism that enables name resolution in a manner that permit clients to locate relevant resources and which provides high availability of these resources.
There have been other methods that have sought to extend the resolution capability in distributed information services.
For example, the Resource Cataloging and Distribution Service (RCDS) developed by the Netlib Development Group of the University of Tennessee is an architecture for cataloging the characteristics of Internet-accessible resources, replicating such resources (to improve accessibility), and for cataloging the current locations of the replicated resources. The integrity of the files provided to the users are ensured using message digests and public-key authentication.
RCDS is a system that consists of several components: (1) Clients, which are WWW browsers and consume the resources provided by the system, (2) File Servers, which provide access to the files required by the client, (3) Resource Catalog Servers, which maintain information about the characteristics of a network-accessible resources and accept queries about these characteristics from clients, (4) Location Servers, which maintain information about the locations of network-accessible resources and accept queries for location data from clients, (5) Collection managers, which manage the files on the file server (it adds, updates and removes files from the file server), and (6) publication tools, which accept new files and descriptions from content providers and inject the files, into the system.
The resolution component of RCDS is composed of the Resource Catalog Servers and the Location Servers. The Resource Catalog Server resolves the URN (or URL) into a Location Independent File Name (LIFN) (using the URC), while the Location Server resolves the LIFN into a URL. From the characteristics (or metadata) present in the URC, RCDS can provide a label that the client uses to reduce the scope of the resolution.
RCDS is inadequate in three ways:
1. There is no added functionality provided in the resolution process in that intelligence (e.g., a simple search engine in the code or access to a search engine in the system) can be used to customize the resource list available to the client;
2. The client cannot negotiate with the service (with or without client intervention) taking into consideration both the client and the service properties to provide the best possible service for the client; and,
3. There is no automatic mirroring of server side objects for ensuring the performance and availability of the service.
In the CNRI Handle System scheme proxy servers are used to permit Web browsers and other clients to resolve names (called handles in their terminology) and caching servers are used to cache previously resolved servers. Here, handles can be resolved based on some characteristics but there is no description or implementation to indicate the manner in which this is accomplished. In this scheme, the caching and proxy servers do not permit negotiation in these transactions. This scheme is also inadequate because it does not permit customized client side searches to locate relevant resources and does not attempt to ensure that accessibility is high by automatic mirroring.